Existing software management and administration products are designed to report isolated events during execution of software and may also report information of operational status of software, but often do so without providing any context. For instance, an error message may be generated for a log file that may report a failure such as a failure to open a file. This error message may not provide any context regarding the severity of this failure. The error may represent a minor failure or it may represent a major failure that places the software in a failed state of operation. There needs to be a way to understand the context of the operational status of executing software when such errors are reported so that a system administrator may appreciate the impact of such an error. In an attempt to provide more context, selected errors or status messages have been reported in a single view or monitoring window but this approach has not relieved the system administrator of the burden to make sense of the error or status messages, nor has it provided the system administrator with a satisfactory appreciation of the impact of the errors. There has been insufficient progress in improving the ability to monitor the health of software using this approach.
Following the approach of model-based testing does not appear to be any more promising. Model-based testing is a current practice for testing software whereby a model of an application is first created using the same requirements used for creating the software, and then test cases are generated and executed by both the application under test and by the model. The results of the tests executed by the application are verified against the results of the tests executed by the model. When discrepancies between the application and the model are detected, the test program alerts the tester. Although model-based testing may provide a framework for generating various combinations of input to the application, the model is only as good as its fit for the application. Taking such an approach for building a health model for monitoring the execution of software has several problems. Inherently, every model is imperfect to the extent that it does not accurately represent the application. However, in the case of model-based testing, the model will not fit the software application to the extent that the requirements are interpreted differently by the software developers who create the software and the modelers who build the model for testing. As a consequence, behavior of the application program may not be accurately reflected by a model constructed in such a manner. Furthermore, attempts to monitor the execution of a software application using such a flawed model will result in frustration due to inaccuracies in the state of execution of the software.
What is needed is a way for constructing a health model that will accurately reflect the state of operation of software or software services. Any such health model should allow a system administrator who may only be interested in monitoring a specific functionality of the product, like a network connection or database availability, to focus on monitoring that functionality.